Рулим дотфайлами. Как быстро повысить комфорт в любом Linux или WSL

.файлы

Помнится, как-то я прочитал статью, которая произвела на меня сильное впечатление. Речь там шла немного не о том, о чем поговорим сегодня мы, однако главная идея та же: большинство системных утилит используют стандартные пути для хранения своих конфигурационных файлов, поэтому совсем несложно создать персонализированную коллекцию настроек для разных программ и восстанавливать их от одного деплоя операционной системы к другому.

Эта концепция стара как мир и носит название «дотфайлы» — файлы, названия которых начинаются с точки, а так как большинство конфигов в никсах и правда начинаются с точки (чтобы стать скрытыми и не мозолить глаза юзеру в выводе ls), то все вполне логично.

Удобнее всего, на мой взгляд, организовать хранение дотфайлов в системе управления версиями (CVS), чтобы можно было клонировать репозиторий одним действием при настройке новой системы. Однако это накладывает определенные условия на то, что́ смогут содержать твои конфиги, так как нельзя забывать, что CVS — штука публичная.

Приватными репозиториями пользоваться бессмысленно — это убьет все преимущества такой организации дотфайлов: например, их не повытаскиваешь из скриптов по отдельности без токенов авторизации. Кто-то может использовать облака для более удобной синхронизации, чтобы избежать миллионов пушей по каждой мелочи. В любом случае это вопрос вкуса, и в этой статье я покажу один из способов, как можно хранить свои настройки на GitHub.

Итак, у меня есть два репозитория.

Первый — dotfiles-linux — конфигурационные файлы для приложений на Linux.

Другие статьи в выпуске:

Xakep #252. Чемоданчик хакера

• Содержание выпуска
• Подписка на «Хакер»-70%

Второй — dotfiles-windows — конфигурационные файлы для приложений на Windows.

В первом репозитории две ветки: master и wsl. Ветка wsl отвечает за версии дотфайлов, которые я использую во втором репозитории для персонализации Windows Subsystem for Linux. Когда при настройке винды я заметил, что никсовые конфиги не получается юзать для WSL «в чистом виде», то решил вести отдельную ветку, которую позже включил в dotfiles-windows в качестве подмодуля.

Результат такой: когда я разворачиваю дотфайлы на новой системе с Windows, я должен выполнить изнутри WSL следующие команды.

Первым действием с помощью wslpath, который резолвит пути между хостовой ОС и WSL, я создаю переменную с именем директории, куда я клонирую репозиторий с моими дотфайлами для Windows. В моем случае директория будет называться /mnt/c/Users/snovvcrash/.dotfiles.

Далее я выкачиваю dotfiles-windows по этому пути.

Последним действием я создаю символическую ссылку в файловой системе WSL. Она будет указывать на подмодуль /mnt/c/Users/snovvcrash/.dotfiles/wsl, который мы заберем с гита, как показано ниже.

Здесь я инициализирую git-подмодуль для данного репозитория на основании настроек .gitmodules, а потом восстанавливаю стейт detached HEAD для всех подгрузившихся подмодулей, так как по дефолту они выкачиваются с отваленными головами.

Если интересно настроить такую же схему, как у меня, это можно сделать с помощью одной команды, которая добавит подмодуль wsl в твой репозиторий дотфайлов из существующего ремоута.

Результат такой же, как если бы я вручную изменил конфиг .gitmodules с помощью git config.

Про концепцию хранения дотфайлов поговорили, а что же, собственно, можно в них хранить? Я остановлюсь только на нескольких тулзах, которыми постоянно пользуюсь в Linux: описание всего, что там лежит, может растянуться на долгие часы.

Zsh

С какого-то момента я перестал воспринимать Bash как шелл, в котором можно комфортно работать. Да, разумеется, если жизнь заставит (особенно если это реверс-коннект с машины-жертвы), можно юзать и обычный /bin/sh без автодополнения, истории и управляющих символов. Но даже реверс-шелл можно довести до ума, проапгрейдив его до PTY, чего уж говорить о дефолтной оболочке на своей машине. Поэтому я использую Zsh. Не писал о нем только ленивый, так что сразу перейдем к минимальному набору приятностей, нужных, чтобы удобно с ним существовать.

Oh My Zsh

В первую очередь это, конечно же, фреймворк Oh My Zsh, позволяющий играючи управлять дополнениями и плагинами Zsh. Маст-хэвом я считаю zsh-syntax-highlighting для подсветки синтаксиса команд в терминале и zsh-autosuggestions для предложения автозавершения команд на основе твоей истории. Установка сводится к выполнению трех простых действий, после которых нужно перелогиниться, чтобы изменения возымели эффект.

Про темы и промпт темы robbyrussell

Zsh не Zsh без цветастого промпта, однако большая часть кастомных тем слишком нагружает интерпретатор, и появляется input lag. Чтобы этого не было, я использую дефолтную тему с одним изменением: ту часть промпта, в которой отражается текущая рабочая директория, я настроил так, чтобы она отражала две родительские папки «назад» и корень, потому что по умолчанию тема robbyrussell показывает только одну папку. Таким образом ты не допустишь засорения экрана при работе в «длинной» директории, но всегда будешь в курсе, где сейчас находишься.

Теперь если заменить %c на %(4~|%-1~/…/%2~|%3~) в файле $ZSH_CUSTOM/themes/robbyrussell.zsh-theme, то все будет по плану.

Source it!

Последним действием я добавляю настройки source внешних дотфайлов, которые лежат в папке ~/.dotfiles/system, в конфиг .zshrc.

## ~/.zshrc
...
## Resolve DOTFILES_DIR
if [ -d "$HOME/.dotfiles" ]; then
    DOTFILES_DIR="$HOME/.dotfiles"
else
    echo "Unable to find dotfiles, exiting..."
    return
fi
## Source dotfiles
for DOTFILE in "$DOTFILES_DIR"/system/.*; do
    [ -f "$DOTFILE" ] && . "$DOTFILE"
done

Там в основном определены дополнительные переменные для экспорта, системные алиасы, настройки виртуальных сред (для Python) и тому подобное.

tmux

Я большой фанат tmux. Это и правда очень удобная штука, которая помогает оставаться организованным при одновременной работе с несколькими сессиями. Для настройки tmux тоже есть туча опций, как и для практически любой линуксовой утилиты.

На мой сетап можно посмотреть на GitHub, а вживую он выглядит примерно так.

Из необычного здесь только панель в правом нижнем углу, на которой висят мониторы системных ресурсов. Устанавливается она отдельно, поэтому я свел процесс настройки tmux в небольшой скрипт (предполагается, что директория .dotfiles со всем необходимым уже существует в твоем домашнем каталоге).

#!/usr/bin/env bash
sudo apt install wget git xclip -y
rm -rf ${HOME}/.tmux*
git clone "https://github.com/tmux-plugins/tpm" ${HOME}/.tmux/plugins/tpm
ln -sv ${HOME}/.dotfiles/tmux/.tmux.conf ${HOME}/.tmux.conf
git clone "https://github.com/thewtex/tmux-mem-cpu-load" ${HOME}/.tmux/plugins/tmux-mem-cpu-load
cd ${HOME}/.tmux/plugins/tmux-mem-cpu-load
cmake .
make
sudo make install
cd -

Tilix

Если ты так же, как и я, влюбишься в tmux, то тебе понадобится минималистичный терминальный эмулятор, не перегруженный лишними фичами вроде создания новых вкладок, хоткеев на copy-paste (так как в tmux у нас все свое) и странной реакции на нажатие правой кнопки мыши. С этим проблематичнее, так как практически все, что я пробовал, уже было заточено под «свою атмосферу», где «тмуксу» были не слишком рады. В итоге я остановился на Tilix для Linux и WSLtty для WSL.

Tilix в конфигурации «из коробки» не попадает под определение минималистичного терминала, однако в отличие от других терминалов все его навороты (автодополнение, панели, верхние менюшки) можно отключить в настройках. В итоге я остановился на голом окне без рамок с эффектом прозрачности и полностью доволен результатом.

Лайфхаки по настройке Kali

Когда делаешь что-то с завидной регулярностью, то волей-неволей вырабатываешь для себя методику, которой стараешься придерживаться в дальнейшем. Вот мои рутинные действия при установке Kali, как в случае с установкой на ВМ, так и на железо.

Первое. Если ставим на ВМ: отключить систему управления питанием, чтобы машина не уходила в сон и не лочила экран. Для меня это обязательная опция, потому что часто работаешь с активной Kali на фоне.

Второе. Если ставим на ВМ: настроить параллельную работу сетевых интерфейсов. Обычно у меня включены три сетки на виртуалке (в терминах VirtualBox): NAT, внутренняя сеть и виртуальный адаптер хоста.

С заводскими настройками Kali не позволяет использовать все коннекты одновременно — NetworkManager не разрешает. Однако если делегировать полномочия управления сетью на старинный ifconfig, то обеспечить одновременную работу сетевых интерфейсов можно, задав соответствующие настройки в /etc/network/interfaces.

$ cat /etc/network/interfaces
## This file describes the network interfaces available on your system
## and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

## NAT
allow-hotplug eth0
iface eth0 inet dhcp

## Internal
allow-hotplug eth1
iface eth1 inet dhcp

## Host-only
allow-hotplug eth2
iface eth2 inet dhcp

## The loopback network interface
auto lo
iface lo inet loopback

После этого поднимаем каждый из указанных интерфейсов, and we’re good to go!

В теории это можно сделать через настройку сетевых профилей для NetworkManager, но я привык по старинке.

Третье. Обновляем систему. Если виртуалка установлена у тебя на рабочей машине, включенной в домен, и ты не можешь выключить антивир на период обновлений (ибо политика не разрешает), то настоятельно рекомендую вытягивать апдейты по HTTPS, чтобы не стриггерить 9999 алертов со стороны хоста. Для этого достаточно добавить букву s в http в файле /etc/apt/sources.list.

Четвертое. На ВМ ставим Guest Additions только тогда, когда что-то из его фич не работает: нативное разрешение не подтягивается либо не действует drag’n’drop или общий буфер обмена. В противном случае оставляем все как есть, потому что обычно готовые образы содержат предустановленные гостевые дополнения, которые, в свою очередь, очень хрупкие и ломаются от любого чиха.

Пятое. Решаем, под каким пользователем будем работать. С правами рута жить проще, но намного опаснее, поэтому рекомендую все же отказаться от суперъюзера хотя бы в том случае, если Kali была установлена на железо. Однако, признаться честно, на виртуалках я продолжаю работать с повышенными привилегиями, так что на этом этапе я задаю пароль для root и отключаю дефолтного юзера kali.

Шестое. Если работаешь под обычным юзером, можно продлить время тайм-аута на ввод пароля для sudo. Опционально и может быть кем-то расценено как небезопасная настройка, поэтому здесь на твое усмотрение.

Седьмое. Устанавливаем cmake, так как он понадобится для сборки софта, и дергаем свои конфиги с GitHub.

После всего этого можно быстро настроить то, что было описано выше, и идти вершить великие дела. Чтобы не вбивать команды по одной, я набросал несколько тематических скриптов, которые выполнят необходимые установки.